Comment changeset status in PRs#625
Conversation
|
Co-authored-by: bluwy <bjornlu.dev@gmail.com>
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
|
This is now ready again. The action now works slightly differently to prevent token leaks when generating the release plan. See the PR description and the added README for more info. I also renamed it as I was also considering adding a simple comment action so we don't have to recommend a third-party action, but I don't want to widen the scope for now. |
| pull-requests: write # to create and update comments on PRs | ||
| steps: | ||
| - name: Comment on PR | ||
| uses: mshick/add-pr-comment@v3 |
There was a problem hiding this comment.
Hm. I like that this is split into two now security-wise, however... I was looking forward to using this new action at work in GHES, as we can't use the bot there. But we also have that nasty requirement that all third party actions must be from verified orgs on GitHub. Given this particular action is from an individual account, we definitely can't use it, so we'd still have to fork and own a copy.
Would be super nice if there was an alternative from a verified org, or if this was still provided as a changesets sub-action. Given all the supply chain security issues lately, I'd be much more comfortable using something directly from changesets and not bring in another variable.
You can test the action with
uses: changesets/action/comment-pr-changeset@comment-pr-changeset-dist.Example workflow setup
See this action ... in action: bluwy/changesets-playground#1 (feel free to send PRs from forks for testing)
This actions focuses only on generating the comment, and defer the commenting to other actions. This is because we want to use reduced permissions for generating the comment to prevent risks of executing untrusted code and accessing the elevated github token. When changesets generate a release plan, we cannot guarantee in the future it will not execute code because of hooks/plugins or such.
When you have this workflow in your repo, you should disable the changeset bot for the repo so messages don't get reported twice. For this action, you should get the exact behaviour and messages from a bot. I didn't change the message for now.